fix(transforms): compile MDX before parsing its imports (depends on #2999) - #3009

Summary

A .tsx page importing an .mdx component 500'd with a message that sent you looking for a file that was sitting right there:

Component has missing dependencies:
  - @/components/snippet.mdx (from …/pages/test/r-tsx-imports-mdx.tsx):
    Failed to read file: Transform failed with 1 error: <stdin>:1:1: ERROR: Syntax error

The file was found and read. The dependency scan of it failed. parseLocalImports hands source to esbuild to strip types before lexing imports, choosing the loader from the file extension — and .mdx maps to the jsx loader. Markdown prose is not JSX, so esbuild rejected byte one, and the resulting exception was reported as a missing dependency.

That also explains the asymmetry the reproducer noticed — MDX importing MDX works fine, because MDX pages are compiled through the parse stage first; only this dependency-scanning path skipped it.

MDX and Markdown are now compiled to JSX first, exactly as the transform pipeline's parse stage does, and the imports are read out of that. .css and .json already short-circuited above this point; .mdx simply had no equivalent handling.

Reproduction

• Route: r-tsx-imports-mdx.tsx
• Test: src/transforms/esm/import-parser.test.ts (new — this module had no direct coverage)

Test evidence

parses imports from a .tsx file ... ok
parses imports out of an .mdx file instead of failing to lex it ... ok
handles an .mdx file with no imports ... ok
short-circuits .css and .json without invoking the compiler ... ok
ok | 1 passed (4 steps) | 0 failed

The MDX cases register a stub ContentProcessor (the MDX extension is not loaded in unit tests) and assert both that the imports are found and that the content compiler was invoked — so the routing of .mdx away from raw esbuild is what is actually under test.

Wider suite: deno task test:unit → 2525 passed | 0 failed.

SSR evidence

$ curl -so/dev/null -w '%{http_code}' http://localhost:3010/test/r-tsx-imports-mdx
200          # was 500

$ curl -s http://localhost:3010/test/r-tsx-imports-mdx | grep -oE 'Snippet</h2>|piece of MDX|point one'
Snippet</h2>
piece of MDX
point one

The MDX renders inline, which is what the route was written to check.

Client evidence

PASS /test/r-tsx-imports-mdx

All six MDX routes in the matrix (n, o, p, q, r, s) now pass the hydration sweep.

Related

• Bug 7 of the reproducer matrix.

Chain: this PR is part of a 13-PR chain fixing the bugs catalogued in
veryfront-router-testing.
Its base is the previous PR in the chain, so the diff shows only this fix.
The root of the chain is #2999 (fix/ssr-lazy-import-graceful-degrade) — merge #2999 first, then
rebase the chain onto main.

Regression gate: deno task test:unit → 2525 passed | 0 failed; deno task lint,
deno task fmt:check and deno task typecheck all clean. The reproducer's full 56-route
matrix (ROUTES.txt + sweep.sh) was re-run after every fix: 7 routes improved, 0 regressed.
A 46-route Chromium hydration sweep (client-sweep.mjs) backs the client-side claims.